The latest updates on your projects. Learn more about Vercel for Git ↗︎

E2E Tests

I like the changes in general, but have some thoughts / concerns:

• Like with call stacks, I think there needs to be a separation between "the point we loaded the data for" and "where we're currently paused". What's trickier in this case is that with call stacks, we jump you to the other frame's line of code, but don't change the pause point. With the "jump" buttons I've got here, that does change the pause point, but in my current mental / behavior model I want to retain the dep graph data for the original point. (Not sure exactly how you changed it yet, just riffing off the description.) I could see a potential argument for not directly exposing the "jump to that earlier point" button, similar to how we do with call stacks, and just selecting the line of code. I guess I'm trying to figure out how you actually would jump to the earlier point if all we do is show you the line, and with call stacks the answers are "add a print statement on the earlier line", or "right-click the frame and 'Jump to Frame' ".
• There is different data that comes back for the "normal" Dep Graph vs the "React" dep graph, which was part of why I had both of those being displayed - to visualize the different data for the same point, and get a sense of what data is coming back.

• There is different data that comes back for the "normal" Dep Graph vs the "React" dep graph, which was part of why I had both of those being displayed - to visualize the different data for the same point, and get a sense of what data is coming back.

From my limited browsing, it seemed like the React path was always a subset of the "full" path. Is that not the case?

• Like with call stacks, I think there needs to be a separation between "the point we loaded the data for" and "where we're currently paused".

With this feature, we're always loading data from the "top frame" (the current point) which is why I have it highlighted as selected (matching our Call Stack UI)

No, there were definitely differences in the results.

In particular, try going to a component that rendered multiple times over the course of the app. Pick a hit point that was triggered by something like a local setState, then load the dep graph.

The normal dep graph focuses on this one current event and how we got here. What you should see is that the "normal" dep graph shows, say, one entry that's Discrete Input click or something like that, whereas the "React" dep graph should show all of the ancestor component ReactElementCreated and ReactRendered entries, at the most recent times that those ancestor renders lead to this component - in other words, the "component stack" data, even though the ancestor components did not render as part of this render pass.

and yeah, with the "jump" buttons, I was treating it slightly differently than call stacks - ie, going to both the earlier line and the point we hit that line. Definitely reasonable for either approach. I'm fine with the change here to match the similarity with call stack behavior.

No, there were definitely differences in the results.

Got it. I'll restore those separate stacks then.

Interestingly sometimes the differences in these stacks look weird. For example, here

I'm paused inside of a React component that's rendering:

But the React dep graph looks less helpful than the normal one:

Yep, agreed, especially in that case. I've been showing bhackett cases like this and asking him to investigate, and he's made several improvements. (Who knows how much longer that will be feasible.)

I guess the thing to do for now will be...I don't even know what. File Linear bugs with Replays attached? Will those even be looked at?

I guess the thing to do for now will be...I don't even know what. File Linear bugs with Replays attached? Will those even be looked at?

We need to discuss this at the company / leadership level. I'm happy to continue working on this but only if we can decide that it's important enough to pull attention away from the other work going on.

I'm happy to continue working on this but only if we can decide that it's important enough to pull attention away from the other work going on.

I was under the impression that the dependency graph feature was pretty central to possible Replay's AI work. Maybe the expectation is that this kind of work shouldn’t require any help from the TT team?

I was under the impression that the dependency graph feature was pretty central to possible Replay's AI work. Maybe the expectation is that this kind of work shouldn’t require any help from the TT team?

OK, I synced with @jasonLaster to get caught up. We do want to continue this work, the plan we talked about is that @bvaughn go ahead and file linear issues around problems with the dependency graph and its react data. @markerikson can focus on fixes and I'll be available to support and help however I'm needed.